home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group00a.txt
/
000093_icon-group-sender _Fri May 12 10:19:29 2000.msg
< prev
next >
Wrap
Internet Message Format
|
2001-01-03
|
5KB
Return-Path: <icon-group-sender>
Received: (from root@localhost)
by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id KAA00987
for icon-group-addresses; Fri, 12 May 2000 10:18:52 -0700 (MST)
Message-Id: <200005121718.KAA00987@baskerville.CS.Arizona.EDU>
From: "Ian Trudel" <ian.trudel@tr.cgocable.ca>
To: "Ray Pereda" <raypereda@hotmail.com>, <icon-group@optima.CS.Arizona.EDU>
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
Date: Fri, 12 May 2000 01:14:09 -0400
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO
----- Original Message -----
From: "Ray Pereda" <raypereda@hotmail.com>
To: <ian.trudel@tr.cgocable.ca>; <icon-group@optima.CS.Arizona.EDU>
Sent: Tuesday, May 02, 2000 1:36 AM
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
> Hi Ian,
>
> >How about investigate a "pluginizable" data type for Icon?
>
> The Jcon design makes it easy to add new data types. In the
object-oriented
> implementation every data type is derived from a common base class that
has
> many useful defaults. Go to the www.cs.arizona.edu/icon to read more
about
> Jcon.
>
> >Data type could be added to the Icon's runtime system on the fly.
>
> I've heard this idea mentioned before. This would take a little bit more
> thinking things through, but it would be a big win for Icon programmers.
Hello,
I agree on this, the extra flexibility given by such system would be
really interesting. It would probably also avoid multiple version, or
distribution, of Icon, such as Unicon, MT Icon, etc. (Speaking of
'distroing', that's something I dislike from Linux. There is like a gazilion
of distro, making the thing hard sometime..)
I've glanced the Jcon source code. Truely remarkable, adding a new data type
is pretty simple. That's not so true for the original Icon system though.
The main problem is the primitive data types are embedded in some
switch()s', so adding a new type requires editing many files and stuff.
That's error prone. However, it would certainly be possible to add a new
dynamic primitive, which would allow us to add new primitives on the fly.
This could also allow either statically linked (with Icon source) or
dynamically linked (shared library or dynamic linked library). This special
primitive could let a third party 'register' his new data type along his
special functions. The primitive system would, of course, expecting some
basic functions such as data convertion or Icon operators, for example. Note
the dynamic primitive data type would requires us to add only one new
descriptor.
But Hey, hang on a minute.. why not rewrite the whole primitive system
(*giggles*) now we speaking of it! A certain system dictionary could
maintain the primitive set and manage them. No need of a dynamic dictionary,
I think the primitive data types should be a limited ressource anyway. A
limit of 255 primitives would be just enough for a while! Anyway, we should
be able to register a primitive to the system (or) primitive dictionary,
along the new functions. If name spacing possible, no need to register basic
functions (such as convertion), they could have standard name (such as
toString, toCSet, toInteger, ..., or fromInteger, etc) or if none found, the
prim's function is automatically failing. This would be also good at the
source code level, each primitive could be a new C file. So, if I want to
dig into CSet functionalites, I glance in primCSet.c (or whatever). Things
are clear in the implementation book and the tech reports, but at the source
code level, it's somehow mixed up and there is no roadmap. Erm..
There is some bad sides of this, of course, like changing the whole source
is not so trivial or making primitives co-existing may be sometimes hard
(hey, what happen if you add a new prim? do we have to add convertion
functions to each other prims? etc)... what else.. a new C interface (for
loadable C fonction) would be needed? Anyway, I'm pretty sure you can find
others.
Icon implementation is not as simple as Smalltalk, for example, but it's
nonetheless interesting. There is lotsa things from Smalltalk (or Squeak)
that could be good in Icon without changing the whole Icon's implementation.
I know the Icon project ppl seeking the stability and portability of their
programming language, but I think the dynamic primitive data type system
would just be awesome!! It'd certainly worth the effort.
Any thoughts?
Ok, I'm off to bed..
Ian Trudel
PS: If you're curious, check out these URL (Squeak primitive stuff):
http://www.create.ucsb.edu/squeak/DIYSqPrims.html
http://minnow.cc.gatech.edu/squeak/464